Abstract 


The majority of Internet of Tilings (IoT) devices are deployed in a central¬ 
ized way as of today, though decentralized in nature. Many problems have 
been exposed: scalability, high operating cost, privacy concerns, security risks, 
and lack of functional values. Blockchain, decentralization by design, could he 
a good solution to these problems. First, blockchain is elastic enough to solve 
the scalability challenge of IoT in a cost-effective manner. Second, retaining 
data within well-scoped blockchains eliminates the concern of IoT data being 
stored in cloud and potentially being leaked or abused. Third, blockchain with 
smart contract and tokens has huge potential to enable autonomous coordina¬ 
tion of devices to create functional values. However, existing blockchains have 
their limitations facing IoT problems because of the special characteristics of 
IoT, such as, large quantity and heterogeneity of devices, and constrains in 
computation, storage and power, etc. 

This paper introduces loTeX, a decentralized network for IoT powered by 
a privacy-centric blockchain with four major innovations: 


Blockchains in blockchain for a well-balanced distributed network that 
maximizes scalability and privacy in a cost-effective way; 


* Tn ic privacy on blockchain based on relayahle payment code, constant- 
size ring signature without trusted setup, and first implementation of 
bulletproof; 

* Fast consensus with instant finality greatly improving the throughput of 
the network and reducing transactional cost; 

* Flexible and lightweight IoTeX-based system architectures purpose-built 
for key IoT applications across multiple industry sectors. 
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1 Internet of Things 

The Internet of Things (IoT) is rapidly emerging as the manifestation of the networked 
society vision - everything that benefits from a connection is connected. Yet, this far- 
reaching transformation is just the beginning. The number of connected IoT devices 
is expected to grow by 21% annually, rising to 18 billion in 2022 [10] and the global 
market of IoT is expected to grow from 170 billion USD in 2017 to 560 billion USD 
by 2022 [15], at a compound annual growth rate of 26.9%. Though many industry 
experts and excited consumers have pegged IoT as the next industrial revolution or 
the next internet, there are three main problems that are holding back the massively 
development and adoption of IoT. 

1.1 Scalability Problem 

The majority of IoT devices are connected and controlled in a centralized way as 
of today. IoT devices are connected to back-end infrastructures on public cloud 
services or on premise server farms to transmit data and receive control commands. 
Currently, the scale of IoT is bottlenecked by the scalability and elasticity of these 
back-end infrastructures, servers and data centers. The substantially high operating 
cost of running the scale of IoT is unlikely to be covered by the profit from selling 
devices. Consequentially, many IoT vendors cannot provide cost-effective devices and 
applications that are scalable and reliable enough for real-world scenarios 35]. 

1.2 Lack of Privacy 

IoT is expected to enable mass participation of end users on mission critical services 
such as energy, mobility, legal and democratic stability. Privacy challenges originate 
from the fact that IoT interacts with the physical world in direct and automatic ways, 
and the amount of data collected will increase substantially when it scales up. Some 
of the common privacy threats, as enumerated in [37 , are: 

1. Identification: Associate a (persistent) identifier, e.g.. a name and address or a 
pseudonym of any kind, with an individual; 

2. Localization and tracking: Obtain an individual's location through different 
means; 

3. Profiling: Compile information dossiers about individuals to infer interests by 
association with other profiles and data sources; 



4, Privacy-violating interaction and presentation: Conveying private information 
through a public medium and in the process disclosing it to an unwanted audi¬ 
ence; 

5. Life cycle transitions: Devices often store massive amounts of data about their 
own history throughout their entire lifecycle that could be leaked during changes 
of control spheres in a device’s life cycle; 

6, Inventory attack: The unauthorised collection of information about the exis¬ 
tence and characteristics of personal things, e.g Burglars can use inventory 
data to check the property to find a safe time to break in; 

7. Linkage: Linking different previously separated systems such that the combina¬ 
tion of data sources reveals (truthful or erroneous) information that the subject 
did not disclose to the previously isolated sources and, most importantly, also 
did not want to reveal, 

All these common privacy threats are due to data leak at device level; or, data leak 
during communication; or, more often, data leak by centralized parties. 

1.3 Lack of Functional Values 

Most existing loT solutions lack meaningful value creation. "Being connected'' is the 
most used value proposition. However, simply enabling connectivity does not make 
a device smart or useful. A greater portion of the value that loT produces comes 
from interaction, cooperation, and eventually autonomous coordination of heteroge¬ 
neous entities. A few good analogies are that individual cells cooperate to build 
multi-cellular organisms, insects build societies, humans build cities and states. By 
cooperating, all these individuals unite to build something that has greater value 
than their own, Unfortunately, according to [29], 85% of legacy devices lack ability to 
interact or cooperate with each other due to compatibility issues. The data sharing 
for business and operational insights is nearly impossible. 

2 Blockchain 

Blockchain technology was introduced in 2008 and its first implementation, i.e. Bit- 
coin, was introduced a year later, in 2000, published in the paper Bitcoin: A Peer-to- 
Peer Electronic Cash System [21. by Satoshi Nakamoto (alias). Essentially, blockchain 
is a distributed, transactional database that, is shared across all the nodes participat¬ 
ing in the network. This is the main technical innovation of Bitcoin and it acts as 
a public ledger for the transactions. Every node in the system has a full copy of 
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the current chain state, which contains every transaction ever executed. Every block 
contains a hash of the previous block, linking these two together, The linked blocks 
become a blockchain. 

2.1 Ingredients 

A blockchain can be perceived as a four-dimensional continuum that has three hor¬ 
izontal layers including transaction and blocks, consensus, compute interface, and 
governance, one vertical layer. 

Transaction and Blocks 

As the lowest horizontal layer, signed transactions are gossiped among all nodes and 
blocks are generated by full nodes. This is the foundation of blockchain where trans¬ 
ferring of digital assets {thus the inherent values) and account security are achieved 
via crypto primitives like elliptic curve signature, hash function and Me ride tree. 

Consensus 

The middle horizontal layer manifests the peer-to-peer nature of the blockchain, where 
all nodes within the network reach consensus on all internal states on chain via tech¬ 
niques like Proof of Work (PoW), Proof of Stake (PoS) and their variants, Byzantine- 
fault tolerance (BFT) and its variants etc. The consensus layer affects scalability the 
most. PoW i.s usually considered less scalable as compared to PoS. In addition, this 
layer heavily impacts security in terms of double spending and other attacks focused 
on mutating the blockchain states in an unanticipated way. 

Compute Interface 

The first two horizontal layers form the shape of a blockchain while the Compute 
Interface layer is critical to make a blockchain useful, which encompasses extensibility 
and usability. For instances, smart contract has been implemented by Ethereum to 
enable programmability where one could count on the distributed "world computer " 
for executing the terms of a contract. Sidechain, together with merged mining, has 
also been developed intensively to support programmability. Second-layer protocols 
like Raiden network [25], state channel has been developed to extend the scalability 
of a blockchain at this layer. In addition, tools, SDKs, frameworks, and GUIs are 
also extremely important to usability. The Compute Interface layer gives developers 
the capability to develop decentralized apps (DApps), an essential part of making the 
blockchain useful and valuable. 
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Governance 


As with organisms, the most successful blockchains will be those that can best adapt 
to their environments. Assuming these systems need to evolve to survive, initial 
design is important, but over a long enough timeline, the mechanisms for change 
are most important, which is known as the vertical layer governance. There are two 
critical components of governance: 


• Incentive: Each group in the system has their own incentives. Those incentives 
are not always 100% aligned with all other groups in the system. Groups will 
propose changes over time which are advantageous for them. Organisms are 
biased towards their own survival. This commonly manifests in changes to the 
reward structure, monetary policy, or balances of power. 


Coordination: Since it is unlikely all groups have 100%- incentive alignment at. all 
times, the ability for each group to coordinate around their common incentives 
is critical for them to affect, change. If one group can coordinate better than 
another, it creates power imbalances in their favor. In practice, a deciding factor 
is how much coordination can be done oil-chain (e.g., votes to the rules of the 
system like Terns 34], or even roll back the ledger if majority stakeholders don’t 
like the change) vs. off-chain {such as Bitcoin Improvement Proposals (BIPs) 

3 ])- 


2/2 Operational Models 

Blockchains can be categorized as permissionless and permissioned depending on how 
it is operated. For example, Bitcoin is per mission less meaning that, anybody can cre¬ 
ate an address and begin interacting with the network, which is "build trust from 
trustless". In contrast, the permissioned bloekehaiu is a closed and monitored ecosys¬ 
tem where the access of each participant is defined and differentiated based on role, 
which is "build trust from less trusted". 

There are benefits and drawbacks to each approach. Regardless, all these con¬ 
siderations boil down to fundamental design trade-offs among trust, scalability, com¬ 
putation and complexity. For example, Bitcoin and Ethereum are blockchains built 
on top of trustless nodes because scalability is strongly desired. Hence, either lots of 
computation is needed (in the case of PoW) or more sophisticated consensus mecha¬ 
nism is needed. In contrast, Fabric lu] is a permissioned bloekehaiu where all nodes 
are considered as trusted and have cryptographic identities, e.g., issued by member 
services like Public Key Infrastructure (PK1), which makes them highly scalable with 
low computation and a relatively straightforward consensus mechanism. 
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Table 1: loT Benefits From Blockchain Properties 


Blockchain Property 

IoT Benefits From 

Dc cent r ali zat ion 

Scalability, Privacy 

Byzantine fault tolerance 

A vailabi li t.y, Sec urity 

Transparency & Immutability 

Anchoring Trust 

Pr (>gr anim al hlity 

Extensibility 


3 Benefits and Challenges of Blockchain and IoT 

Sensing and perception, transformation and transmission, and processing are the 
essence of most intelligent things on this planet. For IoT, while the sensing and 
perception layer is spontaneously distributed, the latter two are not for the time 
being, which is the root for most scalability, privacy and extensibility problems. We 
envision blockchain technology, if it serves as the spinal cord and nervous system of 
IoT, as the best candidate to address the aforementioned loT-specifie problems. 

3.1 Benefits 

By embracing blockchain technology, IoT immediately benefits from the following 
aspects thanks to blockchain s properties including decentralization, Byzantine fault 
tolerance, transparency and immutability. Table 1 summarizes how IoT benefits from 
bio ckchain prop erties. 


Decentr alizat ion 

Decentralization frees users and devices from centralized controlled and consistent 
monitoring, thus partially addressing the privacy concern imposed by centralized par¬ 
ties who monopolize the market and try to understand every aspect of user/device 
for their own benefits, e.p., advertising, Decentralization, under the context of cryp- 
toeconomy, also indicates "elasticity 1 ' that is often defined as 'The degree to which 
a system is able to adapt to workload changes by provisioning and de-provisioning 
resources in an autonomic manner, such that at each point in time the available 
resources match the current demand as closely as possible". A blockchain and the 
underlying cryptoeconomy can be designed in a way that is elastic enough and cost- 
effective enough for IoT scenarios and applications. For example, more blockchain 
nodes could be spun up if the network has enough computation tasks with enough 
incentives to perform. 
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Byzantine Fault Tolerance (BFT) 


The objective of Byzantine fault tolerance is to defend against failures in which com¬ 
ponents of a system fail in arbitrary ways, i, e., not just by stopping or crashing but by 
processing requests incorrectly, corrupting their local state, and/or producing incor¬ 
rect or inconsistent outputs. The Byzantine failure models real-world environments 
in which computers and networks may behave in unexpected ways due to hardware 
failures, network congestion and disconnection, as well as malicious attacks. BFT 
property can be leveraged to achieve many desired security properties in the context 
of loT, eAj.. eliminate man-in-the-middle (MITM) attacks as there is no single thread 
of communication that can be intercepted and tampered, make Denial of Service 
(Dos) attacks almost impossible. 

Transparency and Immutability 

Blockchain provides cryptographic assurances that the data anchored on the chain is 
always transparency and immutable, which can be useful in many scenarios, e.g.. an¬ 
chor states of the loT world on the blockchain for the purpose of auditing, notarization 
and forensic analysis, identity management, authentication and authorisation. 


P r ogr ammabi li ty 

Bitcoin came with basic programmability to allow a transaction to succeed only if 
the underlying small script execute successfully Ethereum enhances this feature 
to achieve the Turning-complete smart contract which is written in high-level pro¬ 
gramming language and executed in a small virtual machine known as EVM. This 
programmability can be and should be extended to loT devices, some of which cur¬ 
rently only have simple and hard-coded logic that can't be further programmed once 
shipped. 

3.2 Challenges 

Benefiting from common properties provided by blockchains does not mean every 
blockchain is suitable for loT use. In fact, it doesn't seem like any existing public 
blockchain can be applied to loT since there are quite a few challenging problems. 

Native Privacy Guarantee Is Not Enough 

Native privacy guarantees from blockchain can only help address the privacy pain 
point in loT to the degree that it retains data on the chain rather than centralized 
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servers, using pseudonymity, However, if a device’s pseudonym is ever linked to its 
identity, everything it ever did under that, pseudonym will now be linked to it. 

No Silver Bullet Blockchain Exists 

As mentioned above, ioT is a universe of heterogeneous systems and devices with 
dliferent purposes and capabilities. It is impossible to find a silver bullet blockchain 
solution that suits most scenarios. For instance, a blockcliain for coordinating millions 
of industrial IoT nodes should focus on high scalability and transaction throughput, 
while a blockchain for coordinating smart devices at home should focus on privacy and 
extensibility. At a macro level, the IoT devices as one specie is definitely evolving 
at a fast pace, i, e., new technologies are integrated, new standards are developed, 
new devices are manufactured with new capabilities. In contrast, at a micro level, 
the individual IoT device’s capability, purpose and operational environment also keep 
changing over time. 

Chain Operations Are Heavyweight 

In the IoT w r orld, many devices are considered as weak nodes because they are: 

• Incapable of performing PoW-based mining due to the power and computation 
constraints: 

• Not able to store large amount of data (e,y, gigabyte level, not mentioning 
terabyte-level and petabyte-level) due to the power and storage constraints; 

• Not able to verify all transactions by processing the whole blockchain; 

• Not able to connect to peers all the time, depending on its uptime and connec¬ 
tivity quality. 


Therefore, most existing blockchains are too heavyweight for IoT, 

3.3 Related Work 

IOTA, which recently launched, is built, based upon unconventional technology known 
as the tangle 24], IOTA attempts to decouple the state transition mechanism with 
the consensus canonicalisation mechanism by throwing away concepts like blocks and 
chain. Instead, transaction issuers are also transaction approvers and transaction 
verification is constructed using a Directed Acyclic Graph (DAG) to make transaction 
fast and zero cost.. The efficiency is obtained by losing globally definite states, which 
makes desired features like Simple Payment Verification (SPY) for light clients and 
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smart contracts quite challenging. loT Chain (1TC) 16], another loT blockchain 
project based in China, inherits the same tangle structure from IOTA, and thus has 
the same pros and cons. HD AC [13] Is another recently proposed blockchain. for IoT 
in Korea, which partnered with Hyundai Group, will focus on more specific fields in 
IoT such as device authentication and Machine-to-Machine (M2M) transaction. 


4 ioTeX: Design and Architecture Overview 

4.1 Design Principle 

IoTeX aims to become the privacy-centric and scalable spinal cord and nervous system 
for IoT. To achieve this and to address the aforementioned challenges, our architecture 
design has the following principles. 

Separation of Duties 

Directly connecting ail IoT nodes into one single blockchain is a dream that can't 
become true. Besides the fact that different IoT applications require fundamentally 
different feature sets of a blockchain, hosting every loT node on one blockchain makes 
it grow fast in size and computation, and eventually become too heavyweight for many 
IoT devices. Instead, a separation of duties makes sure each blockchain interacts with 
a specific group of IoT nodes, and, at the same time, interacts with other hlockchains 
when needed. This is analogous to the internet - heterogeneous devices first form an 
intra-connected group, intranet. Smaller intranets can further form a larger intranet, 
which eventually connects to the backbone of the internet and communicates with 
each other. “Separation of duties 1 " usually creates a well balanced system to maximize 
both efficiency and privacy. 

Occam’s Razor 

Each blockchain has different usages and applications, and should be designed and 
optimized toward different directions. For example, a blockchain that is dedicated to 
relaying transactions between its sub chains does not need to have Turning-complete 
contract running on top of It: another blockchain that connects devices in the same 
trust zone should not care about transactional privacy too much. 

IoT Friendly 

As aforementioned, IoT w r orld is full of heterogeneous systems and nodes, stronger or 
weaker in terms of their resources of computation, storage and power. Since opera- 
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fions that can be done by weak nodes can be easily done by strong nodes, operations 
on the chain should be designed and optimised for weak nodes, he., operations should 
be lightweight enough to conserve resources like computation, storage and energy. 


4.2 Architecture: Blockchains in Blockchain 

loTeX is a network of many blockchains that are hierarchically arranged, where many 
blockchains can run concurrently with one another while retaining interoperability. In 
the loTeX world, as shown in Figure 1, the root blockchain manages many independent 
blockchains, or subchains. A subchain connects to and interacts with loT devices that 
share something in common, e.g., they have a similar functional purpose, operate in 
similar environments, or share the similar level of trust, If a subchain floes not 
function well, e.j., being attacked or experiencing software bugs, the rootchain is 
completely unaffected. In addition, cross blockchain transactions are supported to 
transfer value and data from sub chains to the rootchain or from one sub chain to 
another via the rootchain. 


»■ Constant-size Ring Signature 

; 


Fas! Consensus: VRF + PBFT 


Lightweight Stealth Address 



Figure 1: loTeX: Blockchains in blockchain, a rootchain and subchains architecture. 

The root, blockchain is a public chain accessible by anyone, which has three main 
objectives: 

1. Relay value and data across subchains in a privacy-preserving way to enable 
interoperability among subchains; 
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Table 2: Comparison Between Root chain and Subchain 


Properties 

Rootchain 

Sub chain 

Public vs Private 

Public 

Public or Private 

Scalable 

Required 

Varies 

Robust 

Strongly Required 

Required 

Privacy-centric 

Required 

Varies 

Extensibility 

Non - Turing Coni plete 

Turing Complete 

Instant Block Finality 

Required 

Required 


2. Supervision of subchains, e.g. t penalize the bonded operators of sub chain by 
bond confiscation; 

3, Settlement and anchoring of payments and trust for subchains. 

With these defined objectives, the rootchain specifically focuses on scalability, robust¬ 
ness. privacy-preserving functions and the ability to orchestrate subchains. 

A subchain, on the other hand, could potentially he a private blockchain and relies 
on the root chain as relay to interact with other subchains. A subchain desires flexi¬ 
bility and extensibility to adapt diversified requirements of different loT applications. 
A sub chain is very likely run by operators whose role is contingent upon a sufficiently 
high bond being deposited on the rootchain. Optionally, the system allows operators 
to nominate one or more operators to act for it with or without extra bond. The 
operator acts like a light client on the rootchain, and a full node on the sub chain to 
seal new blocks. 

In all, the properties of the rootchain and subchains are summarized in Table 2. 


4.3 Root Blockchain 


The root blockchain uses UXTO-based model as Bitcoin '211 and Monero (20 for the 
following reasons: 


* Transaction ordering becomes trivial without the need for nonce or sequence 
numbers, which places minimal demands on consensus schemes and allows trans¬ 
actions to be processed in parallel; 


• Applying existent privacy-preserving techniques such as ring signature, and ZK- 
SNARKs for hiding sender, receiver and transaction amount becomes possible. 

The root blockchain is composed of hash-linked blocks, and a block is composed 
of a header that hash-links to the previous block and a. list of transactions, The 
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rootchabi allows primarily two types of transaction: (1) basic transactions includ¬ 
ing P2PKH. P2SH, Mult is ig and etc., and advanced transactions that enable cross 
blockchain operations like Bonds dRegi strati on, Lock. ReLock, Reorg and etc.. Val¬ 
idated transactions are added into a block that has a dynamic size, upper-bounded by 
8MB, A block is produced every three seconds by our consensus scheme as detailed 
in the next section. The rootchain is designed to he non-Tinning-complete with the 
support of a stack-based script and rich set of opcodes. 

4,4 Subchains 

loTeX comes with a framework for developing and provisioning a t ailored sub chain 
for decentralized loT applications by encapsulating low layer primitives like gossip 
protocol and consensus mechanism. The permission model, specification, parameters, 
and transaction types of the subchain can be customized to fit into its application. 

IoTeX subchains use account-based model, which is better for tracking state tran¬ 
sitions. There are two types of accounts, similar with Ethereum, regular accounts and 
contracts. Valid transactions are added into the block, which is produced by the same 
consensus scheme as the root chain to achieve the same degree of finality to make 
cross-blockchain communication more efficient. Subchains either use the root chain's 
token, IoTeXtoken, or define their own token. The token defined by developers on 
subchains can be distributed publicly by token sales or exchanging on public traded 
exchanges. 

Smart contract is supported by subchains and runs on top of the lightweight and 
efficient virtual machine. We are currently evaluating Web Assembly (WASM) [36], 
an emerging web standard for building high-performance web applications. WASM 
is efficient and fast, and can be made deterministic and sandboxed with some mod¬ 
ifications as attempted by EOS project [9 . Other options are also being explored. 
With smart contract, loT devices connected to the same subchain utilize the shared 
state in two ways, 

* First, devices can interact with the physical environment based on their sub- 
chains' states, e.g., light bulbs turn on and off by themselves based on a l( elock 
state” on the subchain; 

» On the other hand, devices can mutate the state on subchains when the physical 
environment changes, e.g., thermostat updates temperature via smart contract 
based on its sensor data. 



4.5 Cross-Blockchain Communication 

Cross-blockchain communication is expected to be used with high frequency in IoT 
applications. There is always the need for an IoT device in a sub chain to coordi¬ 
nate with another device in a different sub chain. Again, limited by IoT devices 1 
low computation and storage footprint, we are motivated to design cross-bioekehain 
communication in a fast and cost-effective way. 

Pegging and Block Finality 

Pegging is a mechanism for scaling the Bit coin network via side chains, originally 
proposed in |1 . It heavily relies on Simplified Payment Verification (SPY 7 ) [21], and 
allows Bitcoins to effectively "move' from the Bitcoin bloekehain to the sideehain 
and back. The underlying idea is simple: Tokens are sent to a special address to be 
locked up on the Bitcoin bloekehain; once this Lock transaction has been confirmed, 
one sends Reorg transaction to the sideehain including the Lock transaction and a 
proof of inclusion in the form of a Merkle branch. The sideehain uses SPY 7 to verify 
Reorg transaction anti, if it is validated, creates the same amount of tokens and 
sends them to a desired address on the sideehain. As of today, pegging serves as a 
primitive for almost all cross-blockchain communication protocols, e.p., Cosmos, Lisk, 
Rootstock. Two separate pegging flows can ho easily coupled together to make the 
so-called Two-Way Pegging (2WP) to make transfer tokens back and forth. 

Block finality is the guarantee that the new r block generated is final and cannot be 
changed. Block finality impacts the concrete implementation of pegging substantially 
as one has to wait, until block finality is achieved (at least with high pliability) on the 
sending bloekehain before requesting to Reorg. Most public blockchains like Bitcoin 
do not have instant finality. The receiving bloekehain can only get a probabilistic 
assurance, e.g.. as more PoW miners confirm a transaction, it is more probable the 
transaction has been accepted. Utilizing a finalizing consensus addresses this problem 
because the receiving chain has assurance with one block confirmation on the sending 
bloekehain. For IoT applications, cross-blockchain transferring of value and data is 
expected to be fast and cost-effective, which requires a finalizing consensus mechanism 
on both root chain and subchains. loTeX consensus achieves instant block finality, 
detailed in the next section. 

Cross-Bloekehain Communication Protocol 

Let s review the protocol at a high level by assuming an address named Charlie on 
sub chain 1 wishes to dispatch a transaction to an address named David on sub chain 
2, and all three blockchains use the same type of token without, transaction fee for 
simplicity. Note that by applying pegging naively, four transactions are needed to 


16 



make a remote call" from sub chain 1 to subchain 2 via rootchain, i.e.. (1) a Lock 
transaction on subchain 1; (2) a. Reorg transaction against rootchain; (3) another 
Lock transaction on rootchain; and (4) another Reorg transaction against subchain 
2. This process indicates David has to wait for at least 4 blocks to accept this “remote 
calf, and data this “remote call" carries needs to be stored on all three blockchains, 
which makes it slow and expensive. We aim to optimize this process by combing (2) 
and (3) into one ReLoek transaction, which not only speeds up the entire process but 
also avoids storing data on subchain 1 and the rootchain. Our protocol is depicted 
in Figure 2. 



Subchain 1 


LocktX, H(D), F/D *Lock1 


Root Chain 


Subchain 2 


Rel_ock{X, H(D) S F/T, P) 



Reorg (X, D, F/T, P 1 )- 



Address 


Figure 2: Cross^Blockchain Transactions 

loTeX cross-blockchain protocol has the following steps, 

1. Each subchain is registered on the rootchain by submitting a transaction called 
BondedRegistration to the rootchain, including its chain name, chain ID, con¬ 
figuration, genesis block, and nomination of operators; This is a one-time pro¬ 
cess; 

2. When Charlie wishes to dispatch a transaction to David, lie initiates a Lock (A', 
H(D) f F/T) transaction where X is the amount of tokens, H ( D ) is the hash 
of the data D to be attached, F/T indicates the from and to addresses including 
IDs for both chains; 

3. Once Lock transaction has been included on subchain 1, Charlie initiates ReLock( X , 
H(D) r F/T, S f F} transaction to the rootchain by inciuding X . H ( D ), Fj 1 1 , 
some current stats of subchain 1 denoted as S as well as proof-of-inclusion F 
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that includes Merkle branches of recent block headers and Merkle branches 
proving Lock transaction has been included; 

4, The root chain validates ReLock transaction and accepts it by including it. in the 
latest block, and creates A' tokens and locked them in a special address; 


5. Once ReLock, transaction has been included on the rootchain, Charlie broad¬ 
casts a ReorgCA , D r F/T f F f ) transaction on root-chain's network with A, 
D , F/T and another pro of-of-inclusion P* that proves the inclusion of ReLock 
transaction; 

6, Operators of sub chain 2 become aware of Reorg transaction, an d they validate 
and create the same amount of tokens on subehain 2 and send them to address 
David with D associated. 

Sharing the Root. Blockchahvs “Bandwidth 71 

One possible concern regarding cross-blockchain communication is that, a malicious 
subchain spams the root chain or another subehain by sending over a huge amount of 
cross-blockchain transactions that exhausted other bloekehairis capacity. One way to 
mitigate is to let. each sub chain bid for its quota and " rate-limit" transactions from 
a subchain if its quota is exhausted. 
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Figure 3: Bandwidth Model for Sharing Rootehain Capacity 

One can define quota based on the storage space within one block. Assuming block 
size is 8MB maximum, and 4MB is reserved for normal transactions happening oil the 
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Table 3: Privacy-Preserving Techniques for Blockchains 


Techinique 

Hide Sender 

Hide Receiver 

Hide Amount. 

Stealth Address 

N 

Y 

N 

Pedersen Commitments 

N 

N 

Y 

Ring Signatures 

Y 

N 

N 

zk-SNARKs 

Y 

N 

Y 


root chain, and 4MB is reserved for all cross-blockchain transactions, which is further 
divided into, say 4096 quota piece with each quota piece to he 1KB. A subchain bids 
for n quota pieces {with a certain upper bound) according to the intended usage by 
putting down a deposit proportional to n. At each round, only up to uKB cun be used 
within a new block for transactions from this sub chain and each such transaction is 
charged a ’ bandwidth” fee from the deposit (to reward miners who help to enforce this 
rule); remaining transactions are queued up and eventually dropped when timeout. 
The quota allocation could be dynamic in the sense that it gets changes when the 
rootchain grows, as shown in Figure 3, If one subchain spams others, it burns out 
its deposit at a fast pace and eventually loses the quota. On the other hand, if 
one subchain puts down a big deposit merely to reserve a big chunk of bandwidth 
without actually using it, the rootchain will have a mechanism to refund part of the 
deposit based on the ratio between the average number of transactions per block and 
the reserved bandwidth, which helps to stabilize the reserved bandwidth close to the 
actual usage. 


5 Built-in Privacy-Preserving Transaction 

The privacy provided natively by Bitcoin and Ethereum is limited to pseudonvmity. 
Transaction details are not confidential The transaction amount and the assets being 
transferred, its metadata, and its relationships to other transactions, can be trivially 
learned by anyone. In fact, there are three aspects of privacy, sender privacy, receiver 
privacy and privacy of transaction details in this context. Various cryptographic 
schemes can be applied to address them, as shown in Table 3. 

loTeX integrates stealth address for receiver privacy, ring signature for sender 
privacy and Pedersen Commitments for hiding transaction amount with the following 
innovations and improvements: 

* A lightweight stealth address scheme is designed to exempt receivers from scan¬ 
ning the entire blockchain to be aware of incoming transactions; 
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• Ring signature is optimized to make it compact in size with a distributed trusted 
setup. 

5.1 Hide Transaction Receiver with Relayable Payment Code 

Stealth Address 

Stealth address technique originated from Cryptonote protocol 28], which solves the 
receiver problem using a half round’ Di file-Hell man key exchange protocol. As¬ 
suming hob wants to hide the fact that he receives tokens from Alice, here is how it 
works: 

1. Bob creates two pairs of private and public keys, denote as (a, A) and (fr.fi?), 
where A = a - G and B — b - G, where G is the base point on an elliptic curve. 

2. Bob publishes public keys (A. B) which are known as his stealth address; 

3. Alice calculates and sends tokens to P — H(rA) ■ G + B using a hash function 
H, a random big number r and hob's stealth address B. This transaction is 
broadcast along with R — r G; 


4. Bob watches all transactions, calculates P f = (H(aR) + fr) ■ G {since he knows 
a, fr. R and G) with the hope that P* equals to P . If P f = P, Bob could spend 
tokens send to P f with private key H(aR) + fr. 


One obvious drawback of stealth address it that the receiver has either to scan 
all transactions (which is not ideal in an IoT world) in the network or rely on the 
assistance of a trusted full node (which compromises privacy to a certain degree). 

Payment Code 

Payment code has been designed to address the above drawback of stealth address 
with a certain sacrifice in privacy. The idea is that. Alice notifies Bob of a payment 
code in a confidential way and Bob only watches transactions against addresses deriv¬ 
ing from that code. Therefore, this proposal has two flows - notification, which is a 
one-time setup between two certain parties, and sending, which can happen multiple 
times between these two parties. 

Assuming Alice has master public-private key pair (mpub AlitM ^ where 

mpubAlice = m P ri Ai^ci ^ and wallet public-private key pair iwpuh Ahc; <.. V-?pri A i ulc ) where 
wpubAlice — wpriAlice r G : Bob has master public-private key pair (mpubtiob, mpriBob) 
where mpub^oi — m P r Gob * G, the one-time notification flow works as below: 
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1. Bob derives Bq =. 6 0 ■ G — {rnprijj (ji) + Hash( 0, seed, metadata)) * G, converts it 
to an notification address ad.dr(B 0 ), publishes it and listens on it 

2, Alice picks a chain code cc at random; {rmpubAtiee. | |cc) is the payment code for 
Alice; 


3. Alice calculates a shared secret S = u)pri Aii( , {f ■ B 0 and sends masked payment 
code P f = (mpu&^iiccllcc) 0 HMAChl2(xof S) to addr(i>o); 

4. Upon receipt, Bob learns wpub ^^, and recovers S — wpub AIiill 6 0 , unmasks B 1 
t o obt ain ( mpub A u Lc \ | cc). 

Once the notification flow is done, Alice and Bob establish one uni-directional private 
channel for sending tokens. The first sending flow works as below: 

1. Alice derives a new address from the her payment code ( that is already shared 
with Bob) by — ao - G — mpubAHtx + Hask{ 0, seed, metadata) ■ G: 

2. Alice selects the next unused public key derived from B 0 . Note that B 0 is the 
unused public key for the first round. 


3. Alice calculates the new shared secret S$ = a# f?o, and calculates the ephemeral 
public key used to send the transaction to which is B f 0 — B (] + SHA256(.%) « G 

4. Bob could derive Aq non-interactively since he knows Alice's payment code, and 
only listens on address derived from — ii Q + SHA256 {,Jjq) ■ G and Sq = A 0 ► f? 0 . 

5. Upon receipt. Bob could use the tokens with private key + SHA256 (l9q). 

The following sending flows works similarly. 

Bob does not need to scan or rely on a full node to scan all transactions. The 
notification transaction does leak the intention of Alice w r ants to send something to 
Bob, but the actual “sending of something' is hidden from everyone else. 

Relayable Payment Code 

To further minimize the privacy leak, w r e designed the relayable payment code on top 
of the original payment code proposal. While the sending flow remains the same, we 
improved the notification flow to make it possible for Alice to secretly share her pay¬ 
ment code with Charlie without using the notification transaction, assuming Alice and 
Bob have one uni-directional private channel, and Bob and Charlie have another uni¬ 
directional private channel. To achieve that, we leverage Hashed Timelock Contracts 
(HTLCs), which require that the receiver of a payment either acknowledge receiving 
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the payment prior to a deadline by generating cryptographic proof of payment or 
forfeit the ability to claim the payment, returning it to the sender, 

Assuming Charlie has master public-private key pair (mpubchariic , ^prichaTiUi ) 
where mpuhchuriit: — m P ri Churh <: r G. The improved notification flow works as follows. 

1. Charlie derives C r 0 = c fl < G — {niprichariiv. + Hash(0. seed, metadata)) - £7, 
converts it to an notification address addrfOa), publishes it.. Note that Co is 
published for Alice to calculate the shared secret., but not for receiving any 
transactions; 

2. Alice generates her payment code (mpubAtiee | |cc) in the same wav; 

3. Alice calculates a shared secret S = wpri Aiic(1 * Co and sends masked payment 

code P* = © HM A Ch 12 (xo fS ) with X tokens as incentive and 

HTLC(Hash 2 (cc)) to Bob using their uni-directional private channel, where 
HTLC\ as part of the locking or redeem script, states that the tokens become 
spendable if the pre-image of Hasfr(v) is given, he.* Hash(cc)] 

-h Bob, incentivized by the tokens sent, over from Alice, sends i y , Y, Y < X tokens 
and HTLC(Hash 2 (v )) to Charlie using their uni-directional private channel; 


5. Charlie, upon receiving Bob's transaction, calculates S = wpub A n cc * c n to un¬ 
mask Alice’s payment code, and spent the transaction by disclosing Hash{cc ), 
which makes Alice-to-Bob transaction spendable to reward Bob. 

Once this flow is done, Alice and Charlie establish one uni-directional private channel 
for sending tokens. It is noteworthy that the routing of Alice’s transaction could be 
multiple hops. 

Our relay able payment codes offer better privacy in terms of hiding the intention 
of "sending of something” on the chain by leveraging the existing private channels 
without adding any computation or storage overhead to the nodes, which, while 
designed for IoT scenarios, is usable for most blockchains like Bit coin. 

5.2 Enable Confidential Transactions 

5*2.1 Problem Statement 

A typical transaction on the Bitcoin blockchain is shown in Figure 4. Essentially, a 
blockchain transactions is just a tuple ({pA:^ *}, {vi ,}), where aie 

input addresses, are output addresses, and {i^} are transaction amounts 

among input and output addresses. Because Bitcoin transactions are stored in clear¬ 
text in the public ledger, it has raised a lot. of security and privacy concerns. 
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Figure 4: A Transaction on the Bitcoin Blockchain 


The goal of confidential transactions (see Figure 5) is to enable only senders and 
receivers of transactions to reveal the values and conceal them from the rest 

of the world. Moreover, confidential transactions also allow other network entities to 
verify the validity of those transactions in question without seeing the actual amounts. 
The realization of confidential transactions on blockchain requires a number of ad¬ 
vanced cryptographic techniques. 
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Figure 5: A Confidential Transaction with Public Verifiability 


5*2.2 Cryptographic Building Blocks 
Proof of Knowledge 

A proof of knowledge, denoted by ( P, V ), is an interactive proof between a prover 
P and a verifier V\ in which the prover wants to demonstrate that he knows some 
information. More specifically, P has (x^w) belonging to a relation IL where x is the 
problem and w is the solution (also called a witness). V knows x and he accepts only 
if P could convince V that he knows w. 
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Zero-Knowledge Proof 


In a zero-knowledge proof protocol, the prover proves a statement to the verifier with¬ 
out revealing anything about the statement other than that it is true, which protects 
the prover against the malicious verifier, which attempts to gain more knowledge than 
what is intended. The protocol can he either interactive or non-intemctive. The key 
difference with non-interactive proofs is that all interactions consist of a single message 
sent by the prover to the verifier. We use the notation NIZKPoK(ct, /?) : a — A b — g H 
to denote a non-inter active, zero-knowledge proof of knowledge of the values a and 8 
such that a = g a and b = All values not enclosed in parenthesis are assumed to be 
known to the verifier. When we use a non-inter active zero-knowledge proof to authen¬ 
ticate auxiliary data, the resulting scheme is referred to as signature of knowledge [8]. 
Basically, a signature of knowledge scheme means that one in possession of a solution 
w to the problem x has singed the message m. For the above NlZKPoK, we use nota¬ 
tion SoK[m](or,j3) : a = g a A b — gf to denote a signature of knowledge on message m. 


Ring Signature 

The concept of ring signature was first introduced by Bivest et a/.[27] in 2001 as a 
special kind of group signature. In a ring signature, the message signer selects a set 
of ring members including themselves as the possible message signers. The verifier 
can be convinced that the signature was indeed generated by one of the ring mem¬ 
bers. However, the verifier is not able to tell which member actually generated the 
signature. Unlike a general group signature, a ring signature scheme does not involve 
designating a group manager for managing the set of ring members, thereby elimi¬ 
nating the possibility of revealing the identity of the actual message signer by the the 
group manager. In order to provide anonymity in smart contract token transactions, 
a special kind of ring signature, so-called linkable ring signature, has been employed 
in the privacy-focused crypto currency Monero [20]. Linkable ring signature has ad¬ 
ditional property that any signatures generated by the same signer, whether signing 
the same message or disparate messages, has an identifier (called a tag) linking the 
signatures. This property enables third parties to efficiently verify that the signa¬ 
tures w r ere generated by the same signer, without leaking the actual signer's identity. 
The linkable ring signature used in Monero is called a Multi-layered Linkable Spon¬ 
taneous Anonymous Group Signature (MLSAG) [22], which is a ring signature on 
a set of key-vectors anti has a communication complexity of 0(m(n + 1)), where m 
is the number of public/private key pairs owned by the signer and n is the size of ring. 
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Accumulator 


One-way accumulators, which were first proposed by Benaloh and fie Mare in [2], are 
defined as one-way hash functions with the property of being quasi-commutative. A 
quasi-commutative function / : X X Y —> X satisfies that, for all x £ X and for all 
3 / 1 , 1/2 £ V, we have 3 / 1 ), yz) = 3 / 2 ), 1 / 1 )■ A one-way accumulator allows us 

to combine a set of values into a secure digest and this digest does not depend on the 
order in which the values are accumulated . It can also be used to generate a witness 
that enables one to attest that a given value is actually part of the accumulator. 

Commitment Scheme 

A commitment scheme is a protocol enabling a user to commit to a value of his 
choice without revealing that value to the recipient of the commitment. In a later 
phase, when the user is asked to reveal the committed value, the recipient will have 
the means to verify that his revealed value is indeed unconditionally linked to his 
commitment. A commitment scheme should meet two requirements. While the hid¬ 
ing requirement prevents the recipient from learning the content of the commitment, 
the biding requirement prevents the user from cheating when opening this commit¬ 
ment. In Pedersen commitment scheme [23], the domain parameters are a cyclic 
group G of prime order q.. and generators (po,. .., g m ). For committing to the val¬ 
ues (uj,... ,v m ) t Z™, one picks a random number r £ and set the commitment 
C = PedCom(t)i. v ni ; r) = g' 0 ]X=i §T- 

5*2.3 Our Improvements 

In [31], Sun et ai presented RingOT 2.0, which employed a cryptographic accumula¬ 
tor to further reduce the communication complexity to O(n) at the cost of additional 
computations. We note that although RingOT 2.0 reduced the communication com¬ 
plexity significantly when compared to MLS AG, the domain parameter generation of 
the accumulator requires a one-time “trusted setup” process liked Zcash. Hence one 
has to trust that whoever generated the secret parameters destroy them when they 
are done, which has raised security and privacy concerns for the system. To address 
this issue, our solution is to employ a secure multi-party computation (SMPC) proto¬ 
col among a set of bootstrapping nodes of the blockchain to generate secret domain 
parameters in a secure and distributed manner. In addition, the following directions 
are currently being investigated to improve the RingCT-like protocols in terms of 
communication and computational overhead: 
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• A new linkable ring signature scheme with communication complexity less than 

O(n) 

• A new approach for aggregating multiple linkable ring signatures 

• A sigma protocol for trustless setup of secret domain parameters 

We aim to propose a novel confidential transaction solution that is able to achieve 
a good trade-off between communication and computation cost., 

5,3 Prove Transaction Amount Range with Bulletproofs 

As a drop-in replacement of Pedersen commitments, bulletproofs [5], a new non¬ 
interactive zero-knowledge proof protocol with very short proofs and without a trusted 
setup, has been proposed recently, which reduces the size of a range proof from linear 
to sublinear and further reduces the transaction size without additional computa¬ 
tion overhead. Since Bulletproofs ht loTeX's design principle well, we are going to 
integrate bulletproofs into loTeX. 


6 Fast Consensus with Instant Finality 

6.1 Background 

Proof of Work (PoW) is the backbone to reach the global consensus of most blockchains, 
including Bit coin and Et here urn. PoW makes it computationally difficult, to construct 
a valid block and attach it to a blockchain, The longer the blockchain becomes, the 
harder it is to reverse any transaction recorded previously by the blockchain. To ma¬ 
nipulate the blockchain, an attacker needs to own T>1 percent of the whole computation 
power of a PoW-based blockchain network. 

Although PoW provides an elegant solution for the global consensus of large dis¬ 
tributed blockchains, it has several inherent drawbacks. The overall computation 
cost to maintain the global consensus is the same cost of the 51 percent attack. This 
means that even if the majority of the blockchain participants are honest, they still 
have to use a lot. of electricity t.o maintain the blockchain, which is not suitable for 
the environment of loT networks that usually favor energy efficiency. In addition, on 
the level of individual devices, computing PoW usually costs a lot of CPU cycles and 
memory usage, which poses difficult requirements to the hardware manufacturing and 
costs of embedded loT devices. 
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6.2 Consensus Design - Randomized Delegated Proof of Stake 

To design and develop a fast and efficient consensus mechanism with instant block 
finality for IoTeX, we plan to adopt the following technologies. 


6.2.1 Proof of Stake 

Proof of Stake (PoS) was proposed as an efficient alternative to PoW for hlockchains 
reaching consensus, which aims to avoid the above mentioned issues of PoW. The 
basic idea of PoS is that a randomly chosen set of nodes vote on the next block, and 

V 

their votes are weighted based on the size their of deposits (i.e. stake). If certain 
nodes misbehave, they may lose their deposits. In this way without computationally 
intensive PoW. the blockchain can run much more efficiently, and can achieve an 
economic stability: The more stake a participant has, the more incentive the node 
has to maintain the global consensus, and the less likely the node misbehaves. There 
are a couple of public PoS designs and implementations, such as Tendermint [32’ that 
has been adopted by many applications (33J. 


6,2.2 Delegated Proof of Stake 

Delegated Proof of Stake (DPoS) improves upon the idea of PoS in the way that DPoS 
allows participants to choose some delegates to represent their portions of stakes in 
the network. For example, Alice can send a message to the network to grant Bob the 
ability to represent her stake and vote on behalf of her. DPoS offers several benefits 
for our loT applications: 


» Small players can pool their stakes to have a higher chance together to partici¬ 
pate in block proposing and voting, and share the rewards afterwards. 

* Resource-constrained nodes can choose their delegates, so not all the nodes need 
to stay online to contribute to consensus. 

• Delegates can be the nodes with strong power supply and network conditions, 
and also can be chosen dynamically and randomly, so we will have a higher 

v Sj v 1 L/ 

overall availability for the network reaching consensus. 


The cryptocurrencies using DPoS include EOS [9] and Lisk [18]. 


6,2.3 Practical Byzantine Fault Tolerance 

Practical Byzantine Fault Tolerance (PBFT) was proposed by Castro and Liskov [7 
in 1999 as an efficient and at tack-resistant algorithm for reaching agreements in a 
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distributed asynchronous network. We plan to use PBFT for the underlying voting 
algorithm of our DPoS consensus mechanism, because it is a concise and well-studied 
algorithm that provides quick finality that is critically important for building an 
efficient and salable blockchain. As demonstrated in Castro and Liskov's original 
paper, PBFT offers both availability and safety if at most a third of the network 
nodes are faulty or malicious, and the network cost of PBFT is very minimum, he. 
about 3 percent compared to unreplicated network system. 

The cryptocurrencies based on PBFT include Stellar [30] and Zilliaq [38]. 


0.2.4 Randomized Consensus based on Verifiable Random Functions 

As mentioned above, for efficiency considerations, when proposing and voting each 
new block, a small group of nodes are selected randomly. The design of the random 
selection algorithm is very important because it. affects the fairness and security of the 
whole consensus process. A group of MIT researchers Yossi Gilad et al recently pro¬ 
posed Algorand [12], which is an efficient PoS consensus algorithm based on Verifiable 
Random Functions (VRFs). 

VRFs were introduced by Micali et at. [19], and can produce publicly verifiable 
proofs for the correctness of their random outputs. By using VRFs, participants can 
privately check whether they are selected for proposing or voting for blocks for each 
round, and then publish their VRF proofs along with the block proposals or votes. 
By using VRFs, we can improve the network efficiency and avoid targeted attacks, 
because selected participants need to broadcast only one message to the network. 


6,3 Creating Periodic Checkpoints for Light Clients 

In loT networks, we expect a lot of devices are light clients , which are the blockchain 
participants that don't record the full transaction history locally. Considering the 
storage overhead of the full blockchain, e.g., over 100GB for Bitcoin 4], many embed¬ 
ded low-cost IoT devices may not have the capacity to download the full blockchain. 
However, these light clients still have ability to quickly verify the correctness of the 
blockchain and interact with it - the design is included in Sat os hr s original Bitcoin 
whitepaper [21], 

However, using PoS instead of PoW has a disadvantage for light clients. When 
verifying correctness of PoS based blockchains, clients need to download a list of public 
keys and signatures for block proposers and voters, and the sets of block proposers 
and voters may change for each block. Thus, when light clients come back online 
after staying offline for a while, the clients may need to download a large number of 
public keys and signatures, and then verify all of them. To mitigate this performance 
issue, Vitalik, the inventor of Ethereum, has proposed creating periodic checkpoints 
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on the blockchain, called epochs [f> , for example every 50 blocks. Each checkpoint 
can be verified based on the previous checkpoint, such that, light, clients can catch up 
with the whole blockchain much faster. 


7 Token on IoTcX Network 

The native digital cryptographically-secured token of the loTeX Network (10TX) is a 
major component of the ecosystem on the loTeX Network, and is designed to 1 je used 
solely on the network. Prior to the launch of loTeX mainnet, the token will exist as 
an ERC20 compatible token on the Ethereum blockchain, which will be migrated to 
a token on the loTeX mainnet when the same is launched. 

lOTX is required as virtual crypto "fuel ' for using certain designed functions on 
the loTeX Network (such as executing transactions and running the distributed ap¬ 
plications on the loTeX Network}, providing the economic incentives which will be 
consumed to encourage participants to contribute and maintain the ecosystem on the 
loTeX Network, Computational resources are required for running various applica¬ 
tions and executing transactions on the loTeX Network, as well as the validation and 
verification of additional blocks / information on the blockchain, thus providers of 
these services / resources would require economic incentives for the provision of these 
resources (i.e. “mining 1 ' on the loTeX Network) to maintain network integrity, and 
lOTX will be used as the unit of exchange to quantify and pay the costs of the con¬ 
sumed computational resources. lOTX will be mineable for 50 years, with rewards of 
the mining reducing over time based on a linear gradient reduction model. 

lOTX is an integral and indispensable part of the loTeX Network, because in the 
absence of lOTX, there would be no common unit of exchange to pay for these costs, 
thus rendering the ecosystem on the loTcX Network unsustainable. 

lOTX is a non-refundabie functional utility token which will be used as the unit 
of exchange between participants on the loTeX Network. The goal of introducing 
lOTX is to provide a convenient and secure mode of payment and settlement between 
participants who interact within the ecosystem on the IoTeX Network. IOTX does 
not in any way represent any shareholding, participation, right, title, or interest 
in loTeX Foundation Ltd. (the Foundation), its affiliates, or any other company, 
enterprise or undertaking, nor will lOTX entitle token holders to any promise of fees, 
revenue, profits or investment returns, and are not intended to constitute securities 
in Singapore or any relevant jurisdiction, lOTX may only be utilized on the loTeX 
Network, and ownership of lOTX carries no rights, express or implied, other than 
the right to use lOTX as a means to enable usage of and interaction with the IoTeX 
Network, 

In particular, lOTX: 
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(a) is non-refundable and cannot be exchanged for cash (or its equivalent value in 
any other virtual currency) or any payment obligation by the Foundation or 
any affiliate: 

(b) does not represent or confer on the token holder any right of any form with 
respect to the Foundation (or any of its affiliates) or its revenues or assets, in¬ 
cluding without limitation any right to receive future revenue, shares, ownership 
right or stake, share or security, any voting, distribution, redemption, liquida¬ 
tion, proprietary (including all forms of intellectual property), or other financial 
or legal rights or equivalent rights, or intellectual property rights or any other 
form of participation in or relating to the loTeX Network, the Foundation, the 
Distributor and/or their service providers; 

(c) is not intended to be a representation of money (including electronic money), 
security, commodity, bond, debt instrument or any other kind of financial in¬ 
strument or investment; 

(d) is not a loan to the Foundation or any of its affiliates, is not intended to represent 
a debt owed by the Foundation or any of its affiliates, and there is no expectation 
of profit; and 

(e) does not provide the token holder with any ownership or other interest in the 
Foundation or any of its affiliates. 


8 loTeX Powered Ecosystems 

The loTeX blockchain supports a variety of IoT ecosystems, shared economies, smart 
home, autonomous vehicles, and supply chain, etc. Different types of developers 
leverage loTeX in different ways. The developers supported by loTeX include IoT 
hardware manufacturers, IoT device control system developers, smart home app de¬ 
velopers, shared economies device manufacturers, supply chain data integrator, data 
crowdsourcing vendors, autonomous cars developers, etc. This section describes a few 
loTeX powered ecosystems. 


8.1 Shared Economies 

In recent years, many companies have focused on shared economies, from rides sharing 
such as Uber/Lyft/Didi, home sharing such as Airbnb, bikes sharing such as Mo bike/ 
ofo, to small item level sharing Like battery bank, umbrella, etc. They all provide 
people with a better living, although some of them are suffering from their business 
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models. It. is a different, topic to discuss their business models; here we mainly focus 
on their technological architecture. Among all shared economies, ride sharing is 
the one that can't avoid human operation, viz., drivers. It is not an loT powered 
economy. However, in the future, when autonomous car technology becomes mature 
and popular, ride sharing will be powered by loT. 

All loT powered shared economies share some similarities: They all require a 
lock that can be opened by a deposit and rental fee. It is very possible and also 
efficient to power the whole sharing and returning process using an IoT device. In 
centralized world, the economies arc powered by a centralized cloud. There are various 
drawbacks: 


1. A large deposit is held by a company that may not be trustworthy. Recently, 
there have been many cases where the company that runs a shared bike service 
in China can't pay back deposits to its users: 

2. The shared economies are not completely driven by community. Many shared 
things are owned by a company. This has caused a waste of society resource. 
Take shared hikes as example. When the shared hikes companies are out of 
business, the bikes are disposed. 

3. Due to the centralized nature, the user data will he stored and controlled by 
one company. There are risk that either the cloud or the client can he hacked 
to obtain user data. 

IoTeX, as an infrastructure, could be utilized to power these applications with¬ 
out the issues above and make shared economies decentralized and more efficient. 
Concretely, an loTcX-powered shared economy provides the following benefits: 

1. Deposit is completely settled by smart contract, With no one holding back the 
money, returning of the deposit is always guaranteed. Users don’t have to trust 
the company to use the service. 

2. Each shared thing realizes its value and mission in an autonomous way. In the 
ecosystem, it doesn't matter who owns the shared things in it. Everyone can 
own and contribute to the ecosystem. The economy can be run by community. 
As a result, companies can play a role of maintaining the loT lock and manage 
the community. It is much lighter business model that companies can fast 
expand and serve more people. 

3. Again, users don’t have to trust the company to maintain their data. Their 
data is kept in the chain with privacy protection. 

Fig. 7 describes how shared economy works based on IoTeX blockchain. 
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Figure G: IoTeX Powered Shared Economy 


8,2 Smart Home 

In the existing smart home market., many IoT device manufacturers are still using 
out-of-date technologies to develop their products. They need a large amount of 
development work on their cloud. The cost of development and maintenance is high, 
and performance is low because of the round trip required to the cloud. Deploying 
their products onto IoTeX blockcliain will largely reduce operating cost on engineering 
and cloud computing, and at the same time, largely increase the performance of their 
devices. In a simple smart light bulb example, with cloud technology, it takes two 
trips from user instruction to changing the state of a light bulb, Manufacturers are 
not cloud experts so often their service is not. optimal. The round trip can take one 
to three seconds. This forces them to use cloud service by big IT companies. There 
are two downsides of using these cloud services: 

1. Manufacturers can't fully control the availability of cloud services. 

2. They need to continuously pay for the cloud service despite their one-time charge 
on selling their IoT devices. 

3. There are risks of their cloud, client side, or intranet being hacked causing user 
data to be stolen or home security problems. 
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In contrast, loTeX blockchain manages the devices locally and interact with public 
chain on the internet when necessary. The public chain is maintained by community. 
There is no maintenance cost for loT manufacturers. loTeX blockchain has privacy 
protection that can prevent leaking data or control being hacked even if the intranet 
is not safe. 



Figure 7: IoTeX-Powered Smart Home 

In addition to allowing loT manufacturers to deploy their loT devices on IoTeX 
blockchain, IoTeX will partner with loT chip makers to develop IoTeX blockchain- 
enabled chips to accelerate the design and manufacture cycles of loT devices. loT 
manufacturers will simply integrate the chip to get their devices supported by IoTeX 
blockchain, 


8.3 Id e lit i ty Man age m c nt 

The growing world of loT has impacted how Identity and Access Management (IAM) 
need to work. In terms of the identity of things, IAM must be able to manage user-to- 
device, device*to-device, and/or device-to-service/system. One straightforward way 
for identity management is to consider IoTeX blockchain as a decentralized PK1 sys¬ 
tem (thanks to its immutability) where each entity is issued a cryptographic identity 
in the form of TLS certificate and the corresponding private. This certificate, which 
















tends to be a short-lived one, is signed by the fie vice's built-in and long-lived cer¬ 
tificate and published on loTeX blockchain (either rootehain or subchain). Peers 
and other entities can access and trust the short-lived certificate anchored on the 
blockchain, and tilings can then authenticate when they come online, ensuring secure 
communication between other devices, services and users, and prove their integrity. 

In addition, the built-in and long-lived certificates for devices could be arranged 
in hierarchy, like the conventional PK1, where parent devices could sign children 
certificate. With the hierarchy, revoking and rotating of certificates becomes possible. 
For example, if one device gets compromised, its parent device or even if grandparent 
device could sign a revocation command and send to the blockchain where the latter 
invalidate the device’s certificate. 


9 Future Research Work 

Some ongoing and future directions of research to improve IoTeX are as follows. 

P rivacy- p reser ving Computation 

There are several areas in this direction we are actively exploring: 

• How to retain confidential states on the blockchain which can he used for com¬ 
puting by a certain group of nodes; 

* Privacy-preserving smart contract where smart contract can be evaluated when 
its business logic is protected by encryption. While fully homophobic encryption 
(2G| and indistinguishable obfuscation schemes II] are the holy grail in theory, 
practical proposals like Hawk 17] is promising for the near future; 

* Further reduce the computation and storage footprint of the privacy-preserving 
techniques IoTeX is currently rising; 

• The quantum-safe version of privacy-preserving techniques IoTeX is currently 
using such as quantum-safe ring signature. 

States Pruning and Transferring 

We are evaluating different ways to safely prune the states stored on subchains to 
reduce the storage footprint since many loT devices have limited storage, Compres¬ 
sion of blocks and transactions is definitely a low-hanging fruit. Besides, transferring 
states from subchain to rootehain (since the latter is stronger in terms of storage) in 
a efficient and privacy-preserving way is also an interesting topic to investigate. 
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Governance and Self-amending 


While IoTeX blockchains offer incentives for maintaining consensus on its ledgers,, it 
does not have a on-chain mechanism for now that seamlessly amends the rules gov¬ 
erning its protocol and rewards protocol development. We plan to conduct research 
on governance and self-amending to address this. 

Tree Structured Blockchains 

The current IoTeX is a two-layer blockchain and naturally, it should be extended to 
a tree of blockchains by leveraging techniques like Plasma and Cosmos. The plan 
is to evaluate these proposal and enhance the current design of IoTeX to eventually 
support more complex hierarchical structures. 


10 Conclusion 


In this white paper, we introduced IoTeX, a scalable, private, and extensible blockchain 
dedicated for Internet of Things, with its architecture and core technologies including 
1, blockchains in blockchain to maximize scalability and privacy, 2. true privacy 
on blockchain based on relay able payment code, constant-size ring signature without 
trusted setup, and first implementation of bulletproofs, 3. fast consensus with in¬ 
stant finality based on VRF and PoS for high throughput and instant finality, and 4. 
flexible and lightweight IoTeX-hased system architectures. 
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